AWS CloudFront導入でコンテンツ取得時間はどれだけ早くなるのか検証してみた。
Amazon CloudFrontの概要
Amazon CloudFrontはAWSが提供するCDNサービスで、離れたリージョンにあるオリジンサーバーからコンテンツを低レイテンシーに取得するために使用するサービスです。
例えば東京リージョンにオリジンサーバーがあった場合、東京に住むユーザーはもともと遅延を感じにくいですが、ヨーロッパに住むユーザーがアクセスをした場合コンテンツの取得時間の遅延を感じることになります。
この距離的遅延を少なくするために登場するのがAmazon CloudFrontです。
上記の図のように初回はユーザーのリクエストがCloudFrontに渡されさらにCloudFrontがオリジンサーバーにリクエストを渡します。
次にオリジンサーバーがCloudFrontにレスポンスを返しますが、この際CloudFrontにコンテンツがキャッシュされるため、2回目以降にユーザーがリクエストを送信した場合にはオリジンサーバーまでリクエストを送らずともキャッシュされたコンテンツをCloudFrontから受け取ることができます。
これによって、ユーザーとオリジンサーバーの距離的遅延の解消だけでなくオリジンサーバーの処理の負担も減らすことができるのがCloudFrontを導入するメリットです。
ではこれによっていったいどの程度の遅延解消ができるのかを早速検証していきたいと思います。
検証
まず下準備としてバージニア北部のリージョンでS3の静的WEBホスティングを使ってこのWEBサイトを表示していきます。
こちらに関してはこちらを参考にしました。
また、この下準備の際にハマった部分はこちらのブログにまとめてあります。
ではさっそくCloud Frontでディストリビューション作成します。
オリジンドメインには先ほど下準備で作成したS3バッケトを選択します。
オリジンアクセスアイデンティティは先に選択したS3バケット用に新しいOAIを作成して、バッケトポリシーが自動で選択されるように設定をします。
この設定をすることでユーザーはCloudFront経由でS3のバッケト内のファイルへしアクセスすることが可能になります。
ビュワープロトコルポリシーはRedirect HTTP to HTTPSを選択します。これでHTTPSのみのアクセスに絞ることが可能です。
Only HTTPSを選べばいいような気もしますがここでOnly HTTPSを選択肢した場合、HTTPリクエストをユーザーが送信した際には403（Forbitn）がユーザーに返されます。Redirect HTTP to HTTPSにしておくことでユーザーがHTTPリクエストを送信した際にも自動的にHTTPSリクエストとして再送信されるため、結果的にHTTPSのみの通信が可能になるようです。
キャッシュポリシーに関してはまずはいったんキャッシュされない場合を検証したいのでCashingDisabledを選択しておきます。
デフォルトルートオブジェクトにはindex.html(S3バケット内にあるファイルの名前）を入力します。
さて、これでいったんディストリビューションの設定は完了です。実際にディストリビューションのドメイン名からサイトにアクセスをしてみます。
Chromeのデベロッパーツールを使って確認をしてみます。まずはCloudFrontが使われているかの確認です。
見るのは、cloudfront.pengのHeardersのx-cacheの項目です。Miss from cloudfrontとなっているので現在Cloud Frontは使われずリージョンから直接アクセスしていることがわかります。
次にキャッシュをする際の準備としてキャッシュポリシーを作っていきます。
ポリシーから新規にキャッシュポリシーを作成していくのですが、ここはすべてデフォルトの状態で作成して大丈夫です。
では続いてキャッシュを使えるようにディストリビューションの設定を変更していきます。
作成したディストリビューションからビヘイビアを選択し、新規にビヘイビアを作成していきます。
パスパターンはstatic/*とします。これでS3バケット内のstaticフォルダ内のファイル（今回の場合は、cssファイル、jsファイル、画像ファイルが入っています。）がキャッシュされる設定になります。
ビュワープロトコルポリシーは先ほどと同じくRedirect HTTP to HTTPSとします。
キャッシュポリシーには先ほど作成したキャッシュポリシーを選択します。これでビヘイビアを作成しましょう。
これでビヘイビアが一つ増えたことが分かります。ビヘイビアは優先順位順に表示されます。
これで再度ドメイン名からアクセスしてみましょう。
デベロッパーツールをのぞいてみると、先ほどMiss from cloudfrontとなっていた部分がHit from cloudfrontに代わっていることが分かります。
しっかりとCloudFront経由でS3バケットにアクセスしているので、何度かサイトを更新してみるとCloudFrontのキャッシュされたデータにアクセスをしてくれます。
では実際にどのくらい速度が速くなっているのか、見ていきます。
先ほどビヘイビアで設定した通り、static配下のファイルの読み込み速度のキャッシュありとなしの差はこんな感じになりました。さらにわかりやすく表にまとめてみると、
差は一目瞭然ですね。cloudfront.png（Other）に関しては約１６倍早くなっていることがわかります。
キャッシュなしの場合に一番早かったstyles.cssの場合でも１３倍以上も速度が早くなっていました。
検証結果
キャッシュありとなしでは格段に通信速度が変わっていることがわかります。実際のWEBサイトの場合はテストサイトよりももっとファイルの数も多いと思うのでCloudFrontの重要性がよくわかりました。
![[アップデート] Amazon WorkSpaces Personalにアイドル切断タイムアウトが導入されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-acc3ac1234c3f431604b3ef32a527e4a/ef41ff2367e43f0b972b2ceec4893544/amazon-workspaces-family)
